QRZ! Ham Radio 5/QRZ Ham Radio Callsign Database - Volume 5.iso/digests/tcp/940200.txt

Internet Message Format | 1994-11-13 | 19.4 KB

Date: Mon, 12 Sep 94 04:30:01 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #200
To: tcp-group-digest


TCP-Group Digest            Mon, 12 Sep 94       Volume 94 : Issue  200

Today's Topics:
                               autoampr
                      ax25 linux implementation?
                             Mail failure

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Sun, 11 Sep 1994 12:20:39 -0600
From: [e-mail] (Bdale Garbee)
Subject: autoampr
To: [e-mail], [e-mail]

I made a comment on one of the mailing lists the other day about having put
together some bits and pieces to help automate the management of an ampr.org
subnet.  A couple of folks contacted me asking for copies of the code.  I
wrote up a README file, shar'ed and gzip'ed it all, and you can acquire it
from

    ftp://winfree.gag.com/packet/gateways/autoampr.shar.gz

Don't bother unless you've got a Unix machine nearby, it's all shell script.

I hope it's useful to someone, has made my life a wee bit simpler.

73 - Bdale, N3EUA

------------------------------

Date: Mon, 12 Sep 1994 10:06:25 +0200 (BST)
From: [e-mail] (Alan Cox)
Subject: ax25 linux implementation?
To: [e-mail] (Glenn Davis)

> Thanks for the feedback on what an AX.25 bsd socket should do.  Can you
> tell me where to find the Linux implementation (source) ?  I will model
> my port after Linux.  Also, there was mention of a few applications built
> on this model; where might they reside?

All reside on ftp.linux.org.uk:/pub/Linux/Radio. The code is derived from
netccitt so you shouldn't have any trouble comparing it against your
netccitt code. The tools that exist currently in the main set are

    call    -    AX.25 connect program with YAPP support
    axl    -    An AX.25 listener - spawns a program for each AX.25
            connect [think of it as a dumb inetd]
    pms    -    Very crude PMS I wrote basically to prove I could
            rewrite AX.25 bulletins/mail into RFC822 and provide
            useful received from lines. Others are now working
            on this.
    axarp/axdelarp/axaddarp - original AX.25 arp manipulation. The current
            Linux net tools support AX.25 implicitly now so no
            special tools are used.
    listen    -    This won't port as it uses SOCK_PACKET (raw interface
            sockets) to monitor AX.25 KA9Q trace style. It's
            derived from the KA9Q trace routines.

    beacon    -    Send a regular beacon (dameon process)

    axattach -    Attach an AX.25 iface (mirror of slattach)
    axsetcall -    Set the AX.25 MAC address on an AX.25 interface
    mheard    -    List who has been recently heard. This uses the
            ax.25 routing table still under addition but collecting
            lists.

On ftp.ucsd.edu you will find the source to some raw socket stuff for talking
to microsat's. You'll also need the xview3 open windows toolkit to build this.
Other people are working on doing BBS code, I'm currently playing with a
very nice hostmode terminal for unix that I want to change to use AX.25
kernel sockets.

If you have any great ideas or think I've done something a paticularly stupid
way then I'm very open to suggestions. I'd rather we had one standard that works
than one that works sort of, even if it means changing the Linux version of
the code.

> I just spent 8 hours finishing the ARP code.  It appears that ARP's are
> not used on point-to-point links normally.  If I read the code correctly
> BSDI just drops them on the floor.  This causes problems since you want
> the interface that the packet arrived on, and this is not available when
> you dequeue the mbuf.
>
> How did the Linux implementation solve this?  My solution was:

Linux doesn't consider the interface point-to-point in AX.25 mode (only
in SLIP mode). The data always happens to be available so that one never
occured. axattach on a (previously) SLIP link clears the pointopoint flags.

The one that was harder to fit nicely into the BSD socket semantics is the
opening phase. I added a little piece of code so that the commonly seen

    SABM
    [wait]
    SABM
    UA
    [Connected]
    UA
    [Reset Connection, Connected]

Doesn't cause a connection refused on the socket but waits until it opens
properly. If data has been sent and another UA turns up then it does reset.

Alan

------------------------------

Date: Mon, 12 Sep 94 06:43:00 edt
From: Adminstrator <[e-mail]>
Subject: Mail failure
To: dayhub!3445a!ucsd.edu![e-mail]


User mail received addressed to the following unknown addresses:
  GPPGDAYTON/GPPGPOST/lshannon

------------------------------------------------------------------------------
Return-Path: <dayhub!3445a!ucsd.edu![e-mail]>
Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id
    <[e-mail]>; Mon, 12 Sep 94 06:43:46 edt
Received: by prowler.daytonoh.ncr.com; 12 Sep 94 06:37:02 EDT
Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 06:36:52 EDT
Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 06:36:55 EDT id AA779367213
    Mon, 12 Sep 94 06:53:33 EST
Date: Mon, 12 Sep 94 06:53:33 EST
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: TCP-Group Digest V94 #199


Received: by ccmail from 3445a.DaytonOH.NCR.COM
>From ncrhub1!ucsd.edu![e-mail]
X-Envelope-From: ncrhub1!ucsd.edu![e-mail]
Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 06:33:35 EDT
Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 06:33:10 EDT
Received: from ncrgw2 by ncrhub1.NCR.COM id ba07109; 12 Sep 94 6:16 EDT
Received: by ncrgw2.NCR.COM; 10 Sep 94 10:12:46 EDT
    sendmail 8.6.9/UCSD-2.2-sun
    Sat, 10 Sep 1994 04:30:10 -0700 for tcp-digest-list
Received: by ucsd.edu; id EAA11034
    sendmail 8.6.9/UCSD-2.2-sun
    Sat, 10 Sep 1994 04:30:09 -0700 for tcp-group-ddist
Message-Id: <[e-mail]>
Date: Sat, 10 Sep 94 04:30:07 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #199
To: [e-mail]

TCP-Group Digest            Sat, 10 Sep 94       Volume 94 : Issue  199

Today's Topics:
                          [e-mail]
                      ax25 linux implementation?
                  Borland C++ 4.0x patches released
                             Mail failure

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Fri, 9 Sep 1994 23:41:36 -0400
From: [e-mail] (Frederick A. Peachman)
Subject: [e-mail]
To: [e-mail]

subscribe

--
Fred Peachman, Brookfield Ohio [e-mail]

------------------------------

Date: Fri, 9 Sep 1994 19:39:21 -0600
From: Glenn Davis <[e-mail]>
Subject: ax25 linux implementation?
To: [e-mail]

Thanks for the feedback on what an AX.25 bsd socket should do.  Can you
tell me where to find the Linux implementation (source) ?  I will model
my port after Linux.  Also, there was mention of a few applications built
on this model; where might they reside?

I just spent 8 hours finishing the ARP code.  It appears that ARP's are
not used on point-to-point links normally.  If I read the code correctly
BSDI just drops them on the floor.  This causes problems since you want
the interface that the packet arrived on, and this is not available when
you dequeue the mbuf.

How did the Linux implementation solve this?  My solution was:

Receive unsolicited ARP reply, or ARP request (broadcast):
 - use IP routing info, or interface this AX25 address last heard on to
   determine interface.  This could result in the wrong interface, and
   potentially requires storing a large number of AX25 address/interface
   pairs.

Receive directed ARP reply:
 - if it was in the table (unresolved request) use it, else drop the packet.

Send ARP reply:
 - send on interface from the arp cache (based on ARP request).

Send ARP discovery:
 - use IP routing, last interface this AX25 heard on, or send to all
   interfaces with a sockaddr in the AX.25 family.

The downside is that the arp table now needs an extra field for the interface.
On the other hand, there is no guarantee that the same AX25 address will not
be heard on more that one interface.

Glenn

------------------------------

Date: Fri, 09 Sep 94 17:19:00 -0000
From: [e-mail] (Mike Bilow)
Subject: Borland C++ 4.0x patches released
To: [e-mail]

The following files may be of interest to NOS developers.

BC4DOS32.ZIP   38K  9-05-94* How to develop 32-bit DOS apps using only Borland
                             C++ v4's RTM. Includes src.
BC4P01.ZIP      5K  9-05-94* Patch file for Borland C++ v4.00
BC4P02.ZIP    129K  9-05-94* Patch file for Borland C++ v4.00
BC4P03.ZIP    441K  9-05-94* Patch file for Borland C++ v4.00
BC4P04.ZIP     65K  9-05-94* Patch file for Borland C++ v4.00 to v4.02

These files are posted for dial-up download at N1BEE BBS, [phone] (to
28800 bps V.34/V.FC), but I don't know of any Internet sites.  I assume they
will be widely available on the Internet.  N1BEE BBS is also supports Fidonet
file requests to 1:323/107.

-- Mike


------------------------------

Date: Fri, 09 Sep 94 11:09:00 edt
From: Adminstrator <[e-mail]>
Subject: Mail failure
To: dayhub!3445a!ucsd.edu![e-mail]



User mail received addressed to the following unknown addresses:
  GPPGDAYTON/GPPGPOST/lshannon


------------------------------------------------------------------------------

Return-Path: <dayhub!3445a!ucsd.edu![e-mail]>
Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id
    <[e-mail]>; Fri, 09 Sep 94 11:09:20 edt
Received: by prowler.daytonoh.ncr.com; 9 Sep 94 11:04:41 EDT
Received: by dayhub.DaytonOH.NCR.COM; 9 Sep 94 11:04:15 EDT
Received: by 3445a.DaytonOH.NCR.COM; 9 Sep 94 11:04:47 EDT id AA779123936 Fri,
    09 Sep 94 11:18:56 EST
Date: Fri, 09 Sep 94 11:18:56 EST
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: TCP-Group Digest V94 #198


Received: by ccmail from 3445a.DaytonOH.NCR.COM
>From ncrhub1!ucsd.edu![e-mail]
X-Envelope-From: ncrhub1!ucsd.edu![e-mail]
Received: by 3445a.DaytonOH.NCR.COM; 9 Sep 94 11:03:11 EDT
Received: by dayhub.DaytonOH.NCR.COM; 9 Sep 94 11:02:21 EDT
Received: from ncrgw1 by ncrhub1.NCR.COM id be12293; 9 Sep 94 11:01 EDT
Received: by ncrgw1.NCR.COM; 9 Sep 94 10:57:44 EDT
    sendmail 8.6.9/UCSD-2.2-sun
    Fri, 9 Sep 1994 04:30:13 -0700 for tcp-digest-list
Received: by ucsd.edu; id EAA25167
    sendmail 8.6.9/UCSD-2.2-sun
    Fri, 9 Sep 1994 04:30:11 -0700 for tcp-group-ddist
Message-Id: <[e-mail]>
Date: Fri,  9 Sep 94 04:30:06 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #198
To: [e-mail]

TCP-Group Digest            Fri,  9 Sep 94       Volume 94 : Issue  198

Today's Topics:
                           9k6 on-air test?
                  RE> KPC-9612 and X1J (IP routing)
                      TCP-Group Digest V94 #197
                   TCP-Group Digest V94 #197 (fwd)

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Thu, 8 Sep 1994 21:42:43 -0700 (PDT)
From: [e-mail] (Jerome Kaidor)
Subject: 9k6 on-air test?
To: [e-mail]

   Is there anybody on this list who's in the the San Francisco Bay
area and could help me with an on-the-air test of my new 9600-baud
packet station on 2M?

   It does receive, but there's nothing much happening on the local
9k6 frequency.  Just one station that keeps sending:

N6LDL-1>ID:Network node (#LGNODE)

   When I try to connect to it, nothing happens.  I assume its a NET/ROM
node, or somesuch.  But then, I have no idea if my transmit level is
reasonable.  Is there, perhaps, an AX25 BBS or two on 9k6?

  My goal is to get the thing working on 70CM tcp/ip, but it seemed
simpler to get the ax25 stuff working first....


                           - Jerry Kaidor, KF6VB



------------------------------

Date: Thu, 8 Sep 1994 20:46:36 -0600
From: [e-mail] (Evan E. Idler, Edmonton, AB  [192.75.200.5])
Subject: RE> KPC-9612 and X1J (IP routing)
To: [e-mail]

It was mentioned that it would be nice to have the kpc-9612 to route ip
on a remote site, as a dual port router.  Well, I had a nice talk with
Ruth Hull at the  Radio Amateur Of Canada Convention last month, and this
topic came up.  Well it seems, that If enought write The president of
KANTRONICS, they will port X1J over to run on it.  However if there is not
enought people requesting it, they will not be undertaking the project.

SO, IF YOU WANT IT YOU ALL HAVE TO TELL THEM THAT YOU WANT IT!!!!!!!!!!!

I beleive the person to Write your letter to is:

Karl Medcalf
Kantronics Co., Inc.
1202 E. 23rd Street
Lawrence, KS 66046


So write him, tell him how much you like your new KPC-9612, but how much
you would also like it to run X1J code.  If enough people ask, they will do
it.

73
EVAN


=======================================================================
Evan E. Idler                     |         Of All The Things I've Lost
[e-mail]          |         In Life, I Miss My MIND The
Edmonton, Alberta, Canada         |         Most!!!
Amateur Packet Radio Station VE6EEI [192.75.200.5]
=======================================================================

------------------------------

Date: Thu, 8 Sep 1994 10:20:54 -0800 (PDT)
From: [e-mail] (John Paul Morrison)
Subject: TCP-Group Digest V94 #197
To: [e-mail]

>
> Date: Wed, 7 Sep 1994 20:05:09 -0600
> From: Glenn Davis <[e-mail]>
> Subject: ax25 on bsd
> To: [e-mail]
>
> I have started the work to complete Brian Kantors AX25/KISS driver on BSDI.
> The stuff that is missing is: arp, good routing, and the socket interface
> (via pr_usrreq hook in the protocol switch table).
>
> Has anyone given much thought to the semantics of how sockets should be
> used when talking ax.25?  The IP stuff will remain pretty much the same,

Why don't you follow what the Linux AX.25 sockets do, since that is
already a working implementation.

> but I want to keep the ability to connect to non-ip packet bbs's.  The
> intent is to run a modified telnetd (using the ax25 protocols) to allow
> incoming connections.

I have patched BSD rlogind to work on a Linux AX.25 socket. It's not
really rlogin any more, as I've stripped out most of what's not needed
for AX.25, I just used it because it handled all the pty and login
shell stuff. I looked at telnetd for this, but it's too bloated and difficult
for me to figure out what to disable or fake for AX.25.

A linux program called axl listens on the AX.25 interface. When it
gets a connection, it forks off ax.rlogind, then goes back to
listening, and that gives you a login: prompt. You can login and get a
shell prompt. When you login you have to stty a few things (I think
/bin/login changes the tty modes, so even if I did set the line mode in
ax.rlogind, login would just change it back). I should change ax.rlogind
to use skeylogin to prompt for passwords. (which reminds me: does anyone
have an Skey available for an HP48 or other small calculator, so you
can calculate the response to the challenge without doing it by hand
or installing skey on every machine you visit)

It's quite horrible really, but it works. I don't think 1200bps packet
with a line at a time entry is useable for much with a login shell, but
instead of starting login, you could start up a bbs process, or some mail
stuff.


>
> glenn/ve6rsx
>

---------------------------------------------------------------------------
BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  --
[e-mail] [e-mail] [e-mail]
---------------------------------------------------------------------------

------------------------------

Date: Fri, 9 Sep 1994 11:38:39 +0200 (BST)
From: [e-mail] (Alan Cox)
Subject: TCP-Group Digest V94 #197 (fwd)
To: [e-mail]

In-Reply-To: <[e-mail]> from "John Paul Morrison"
at Se
p 8, 94 10:20:54 am
> Why don't you follow what the Linux AX.25 sockets do, since that is
> already a working implementation.

This seems sensible as we have nice tools and I'm also open to alterations
as suggested.

The AX.25 socket layer basically works as follows under Linux

 SOCK_RAW gives raw AX.25 access where the type of socket is
 the AX.25 PID. Datagrams or VC delivered raw and you fix it.

 SOCK_DGRAM UI AX.25 protocol frames. Marked with the AX.25 type

 SOCK_SEQPACKET AX.25 connection mode.

Since its derived from the BSD netccitt LAPB code the same hacks to
it should work roughly for BSD networking. It's got other stuff like
setting window, t1,n2,t3 via setsockopt.

Following that core setup would make most stuff portable (which as we all
know is good news).

Alan

------------------------------

End of TCP-Group Digest V94 #198
******************************

------------------------------

End of TCP-Group Digest V94 #199
******************************

------------------------------

End of TCP-Group Digest V94 #200
******************************